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I. INTRODUCTION 


The IoT has invaded all the sides of our life and plenty 
of new applications are emerging in different fields of our 
environment. Furthermore, more and more technologies 
related to the IoT are opened out to the benefit of 
improving the quality of life. Nevertheless, although the 
fast progress of IoT and related technologies, the need for 
suitable and appropriate solutions involving constrained 
devices is necessary to overcome the problem persisting 


like network congestion. 


The Constrained Application Protocol CoAP has been 
designed by the Internet Engineering Task Force (IETF) to 





Abstract— Lightweight devices and constrained resources used in the 
Internet of Things (IoT) applications have developed in exorbitant 
numbers, generating a large amount of data required for intelligent data 
processing. One of the foremost emerging messaging protocols used to 
address the requirements of these lightweight IoT nodes is Constrained 
Application Protocol (CoAP). Considering the unlimited number of 
messages and notifications generated by these devices, the problem of 
congestion occurs in CoAP communications. In this context, to fulfill 
successfully the need of transactions and succeed to handle reliably 
unicast and multicast communications, CoAP dispose of congestion 
both 
communications. The challenge addressed in this paper consists of 


control mechanisms to manage unicast and multicast 
designing appropriate congestion control mechanisms for CoAP that 
ensures a secure network operation while keeping the utilization of 
network resources efficiently. Therefore, in this paper, we shed the light 
on congestion control algorithms used to manage unicast and multicast 
communications CoAP based; we present a critical analysis of its 
performances and highlight some of its shortcomings and pitfalls. We 
combine and put forward two of our proposed adaptive algorithms of 
congestion control based on network conditions in both unicast and 


multicast communications. 


operating in a constrained environment. It defines two 
interactions types between end-points based on 
client/server model: a) One-to-one interaction 
(request/reply) and b) Multi-cast interaction (Client wants 
to interrogates multiple servers). Like HTTP, Clients have 
the power to manage resources using requests: GET, PUT, 
POST and DELETE to perform Create, Retrieve, Update, 
and Delete operations. 


CoAP has successfully fulfilled the need of the 
lightweight features required to handle communication 
between constrained devices in JIoT environment. 
However, these devices are generating an enormous 


support IoT with lightweight messaging for devices 
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amount of messages and notifications that cause the 
network congestion. 


Network congestion in CoAP represents the great 
limitation that hinders the right functioning of this protocol 
and causes the loss of packets. It can also significantly 
damage the performance of a network, manifesting in 
increased packet latencies, while a network may even 
become useless if the congestion collapse occurs [1]. On 
the other hand, unlike HTTP, CoAP does not run over 
TCP, it runs over UDP. 


Consequently, the challenge addressed in CoAP based 
communication consists of designing a suitable congestion 
control mechanism that ensures a safe network operation 
while keeping the use of network resources efficiently. 


Communication between clients and servers is afforded 
through connectionless datagrams. Retries and reordering 
are implemented within the application stack. So, 
retransmissions management is a challenge in CoAP. 
CoAP also allows UDP broadcasts and multicasts for 
addressing [2]. In this 
communication types Unicast and Multicast CoAP based 
communications. 


paper, we discuss two 


communications, CoAP allows 
communications between single nodes (client to server or 
server to client). So, it must compute an adequate 
Retransmission Time Out (RTO) for the next transmission 
for each node. In this context, the core CoAP specification 
defines a basic congestion control mechanism that consists 
of the utilization of a back off mechanism to compute the 
Retransmission Time Out (RTO) for subsequent 


transmission. It is based on the use of a fixed RTO value 


In unicast 


that is doubled in each retransmission. Nevertheless, albeit 
the core CoAP specification defines a basic congestion 
control mechanism to make it ready to handle congestion 
control by itself, researches have proved that CoAP is not 
capable of being adaptive to network conditions. 


To address all those aforementioned problems, many 
congestion control algorithms were proposed. In this paper 
we present the most important ones, we compare them and 
we highlight our own adaptive solutions. 


On the other hand, in many IoT application fields, 
additionally to unicast communication, nodes should be 
addressed in groups, so as to manage the requirements of 
multiple communications between different and several 
devices, CoAP supports group communication [3]. 
Multicast communication is a communication driven from 
a single node to multiples nodes (client to servers or server 
to clients). However, CoAP 
communication in one sense, from a server to multiple 
clients, but in the other sense -from a client to multiple 
servers- , it relies on unicast communications. This has led 


ensures multicast 
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to the problem of network congestion [4]. To resolve this 
problem, researchers propose to insert a delay between 
consecutive requests. 


In addition to a review of congestion control 
algorithms in multicast CoAP based communication, we 
discuss our own proposition of the delay to insert between 
two requests. 


The remainder of this paper is organized as follow: A 
description of CoAP congestion control algorithms in 
unicast communication is presented as well as our 
proposed adaptive algorithm in the second section. Then, 
in the third section, related works to group communication 
in CoAP including multicast group communications are 
described. Afterwards, the proposed improved congestion 
control algorithm is detailed. Finally, a conclusion and 
some future directions are closing up our paper in the 
fourth section. 


II. COAP CONGESTION CONTROL IN UNICAST 
COMMUNICATIONS 


2.1. Basic CoAP congestion control algorithm 


Although, CoAP has become increasingly proposed 
and proved its effectiveness in gathering data from smart 
sensors and controlling constrained devices, the problem 
of network congestion in CoAP represents the great 
limitation that causes the packets loss. 


Indeed, the core CoAP specification defines a basic 
congestion control mechanism that consists of the use of a 
backoff mechanism to compute the Retransmission Time 
Out (RTO) for the next transmission. It is based on the use 
of a fixed RTO value, which is doubled in each 
retransmission. Nevertheless, even if the core CoAP 
specification defines a basic congestion control mechanism 
to make it able to handle congestion control by itself, 
researches have proved that CoAP is not capable of being 
adaptive to network conditions and this goes back to the 
fact that it doesn’t take into consideration the RTT of a 
packet since the network conditions may change 
frequently because of the dynamic topology and the 
density of WSN nodes [5]. Therefore, the calculation of an 
appropriate RTO is essential to overcome the problem of 
congestion. 


2.2. Classical TCP congestion control algorithm 


Unlike the basic CoAP congestion control that uses a 
fixed RTO, the computation of RTO in the classical TCP 
congestion control is based on the history variation of 
RTT. The specification of this algorithm is proposed by 
RFC 6298 [6]. 
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According to this specification, the calculation of the 
actual RTO to use in the next transmission is based on two 
variables; smoothed average of RTT (SRTT) and RTT 
variation (RTTVAR); where SRTT is used to preserve the 
history of RTT and RTTVAR keeps the history of RTT 
variation. Both of these parameters are constant and their 
impact factors respectively are 7/8 and 3/4. 


Initially, the RTO value is set to 1 second. After the 
first transmission, the first RTT value is received. To 
compute the following RTO value, SRTT is set as RTT 
received and RTTVAR is set as RTTreceived/2, the 
following formulas are used [7]: 

SRTT = RTT 
RTTVAR = RTT/2 


After subsequent RTT measurements are received, the 
following formulas are applied: 


SRTT = (1 - a) * SRTT + a * RTT (1) 
RTTVAR = (1 - $) * RTTVAR + B * |SRTT - RTTI (2) 
RTO = SRTT + max (G, K*RTTVAR) (3) 


The formula (3) is used to estimate the RTO value to 
be used in the following transmission. When the RTO 
timer expires, the RTO value is doubled [8]. 


According to RFC 2988, the value of the constant K in 
(3) is 4. Furthermore in (1) and (2) a and B are also 
constants and their values respectively are 1/8, 1/4. 


Moreover, the G value defines the clock granularity in 
seconds and according to experiences, finer clock 
granularities inferior or equal to 100 ms perform somewhat 
better than other granularity values [8]. Thus, it is 
recommended to choose the G value not greater than 100 
ms [6]. At the same time, G should be at least one order of 
magnitude smaller than the RTT [9]. 


2.3. CoCoA 


Since the basic CoAP congestion control mechanism 
can hardly meet the requirements of many IoT 
applications, several approaches were proposed to improve 
the aforementioned CoAP shortcomings. The CoAP 
Simple Congestion Control/Advanced CoCoA [10] is the 
most important extension of CoAP that has been 
standardized by IETF. Indeed, basic CoAP does not care 
about the network characteristics; it behaves the same way 
in any type of network. Therefore, in order to optimize the 
CoAP congestion control abilities, CoCoA, based on TCP 
RTO estimation algorithm, uses RTT measurements to add 
state information about individual RTOs for different 
destination endpoints. CoCoA algorithm is based on two 
mechanisms: (i) a strong estimator; the packet is received 
on the initial transmission without any retransmissions and 
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(ii) a weak estimator; RTT value is measured after at most 
two retransmissions. Both of these mechanisms implement 
the same algorithm but have different sets of state 
variables. The overall RTO estimated in the formula (6) is 
made from the estimator that made the most recent 
contribution using either formula (4) or formula (5) [9]. 


RTOrecent = 0.25 * RTOweak + 0.75 * RTOrecent (4) 
RTOyecent = 0.5 * RTOstrong + 0.5 * RTOrecent (5) 
RTOoverait = 0.5 RTOrecent + 0.5 = RTOoverait (6) 


The fact that CoCoA uses a constant backoff factor and 
RTO aging mechanism penalize its performances. The 
reason why authors in [11] propose a mechanism using a 
variable backoff factor depending on the estimated RTO 
called CoCoA+. The improvement in this mechanism 
helps to avoid quick retransmissions for low RTO values, 
and to avoid slow retransmissions for large RTO values. In 
addition, in the case when the RTO value has not been 
updated for a long time, CoCoA+ adds an incorporated 
RTO aging mechanism. 


Furthermore, in [12], the authors design a 4-state 
estimator scheme for CoCoA depending on the number of 
times a packet has been retransmitted. The transaction 
starts in state 1, and each time a packet is retransmitted, its 
state increases by one. Each time a packet is successfully 
transmitted and acknowledged within its stipulated time, 
its state decreases by one. This allows setting the backoff 
parameters accordingly. 


Nevertheless, in the presence of a high number of 
packet losses, subsequent updates of the weak RTO 
estimator can cause some unexpected or unpredictable 
problems [13]. Since CoAP limits the Max_Retransmit in 
four, a new RTTweak might be obtained after the second, 
third, fourth, or fifth transmission. Thus, the specification 
of correspondence between each transmission and its 
CoAP acknowledgment might be not possible. This 
mechanism may have a great impact on the calculation of 
the overall RTO. In addition, when the RTT wea is 
measured after multiple retransmissions, the new 
calculated RTO might increase in a considerable way 
compared to RTOinit. 


So, in the aforementioned congestion control 
mechanisms, the issue of setting a right RTO value with 
burst traffic is still limited because setting a correct and an 
accurate RTT of retransmitted packet is hardly obtained 
[14]. In table 1, CoAP congestion control algorithms are 
listed with basic characteristics. 


Table .1: CoAP Congestion control algorithm’s 
characteristics 
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Algorithm Backoff RTT RTO Derived 
method estimation aging from 
CoAP BBF None No None 
CoCoA VBF Strong & Yes Linux 
weak RTO 
CoCoA-S VBF Strong & Yes CoCoA 
weak 
CoCoA-E VBF Strong & Yes CoCoA 
weak & Eifel 
4-state- VBF Four Yes CoCoA 
strong estimations 





Il. COAP CONGESTION CONTROL IN 
MULTICAST COMMUNICATIONS 


In the IoT, applications use group communication to 
make transactions between its different nodes, this goes 
back to the fact that nodes should be addressed either 
individually or in groups. 


In many IoT applications, nodes addressed in group, 
i.e., a one to many communication patterns is essential to 
meet the needs of the application. Furthermore, in some 
applications, to increase the accuracy and the reliability of 
gathered data, it is important to collect information from 
more than one sensor. Moreover, the information gathered 
at the same time from many sensors may be very crucial to 
decide the appropriate way to intervene in situations that 
require real time intervention. So, all these scenarios and 
others require a communication with a group of sensors as 
recognized in the Charter of IETF CoRE Working Group 
[15]. 


IETF CoRE working group has first recognized the 
need to support a non-reliable multicast message. Thus, 
they have developed a specification for Group 
Communication for CoAP in RFC 7390 [16] to explain 
how we can use the CoAP protocol in a group 
communication context. Indeed, Group communication 
based on CoAP consists of sending a single non- 
confirmable message to multiple nodes grouped into a 
specific group using UDP/IP multicast for the requests, 
and unicast UDP/IP for the responses (if there was any). 
This means that all the nodes grouped in this group receive 
the same exact message [17]. 


It was proved that the use of multicast communication 
for sending requests is very efficient but it does not affect 
the number of responses sent by the destination nodes 
since these are sent as unicasts. In the same context, 
authors in [18] presented an alternative lightweight 
forwarding algorithm for efficient multicast support in 
Low-power and Lossy Networks (LLNs). This allows 
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reducing a number of requests in the LLN since it sends 
one request to multiple destinations at the same time 
instead of a unicast for each destination. 


The problem of congestion happens when the traffic 
load offered to a network approaches the network capacity 
[19]. This phenomenon is one of the main obstacles that 
still hinder the well functioning of many protocols and 
thus impacts directly the efficiency of the communication. 
On the other hand, requests in group communication using 
CoAP engender a multitude of responses from different 
nodes, potentially causing congestion. Therefore, both the 
group communication multicast-based requests and the 
group communication CoAP unicast-based responses to 
these multicast requests must be conservatively controlled. 


Indeed, it defines a random delay called leisure that 
consists of a period of time delay inserted between 
multiple multicast requests. This leisure could be a default 
value either used by the server or computed according to 
formula (7). 


Leisure = S*G/R (7) 


Where, G is an estimated group size, R is a target data 
transfer rate R and S is an estimated response size. 


Nevertheless, in the case when a single client is 
communicating with multiple servers using unicasts, 
CoAP does not specify a congestion control mechanism. 
To overcome this situation, authors in [20] proposed a 
simple solution consisting of a delay inserted between 
consecutive requests; this led to a limitation in the rate at 
which requests are sent. 


In the following paper, we propose an improved 
formula to calculate the estimated delay to introduce 
between requests in order to reduce the network 
congestion. 


IV. RESULTS AND DISCUSSION 
4.1. Adaptive unicast congestion control algorithm 


In addition to the fact that the basic CoAP congestion 
control does not use the RTT of previous transactions to 
estimate the following RTO, it also does not take into 
consideration the utility of the packet loss ratio as well, to 
adapt its behavior to network conditions. 


The packet loss is defined as the number of packets 
that failed to reach their destination across a computer 
network. Packet loss is caused either by link-layer 
interference or by network congestion and it is measured 
as a percentage of packets lost according to packets sent. 


Indeed, in IoT networks, the packet loss is considered 
one of the big consequences of the network congestion 
problem. Based on this fact, in [20], we propose an 
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improved congestion control algorithm based on the 
packet loss ratio and the RTT value considered in the 
previous transmission. 


Furthermore, in order to provide an adaptive dynamic 
retransmission timeout that can be suitable for network 
conditions in the IoT applications, we propose to update 
the RTO value in each retransmission according to the 
packet loss ratio. The correlation between actual and 
previous RTO values seems primordial to adapt the recent 
RTO value to network conditions. Basically, the RTT and 
the packet loss ratio which is in a frequent change. 
Therefore, there is no need to aging techniques because 
our RTO is in a frequent change according to the packet 
loss changes and it will never keep a fixed value for an 
extended period. Thus, the server notifies the client with 
the packet loss ratio based on sequence numbers of 
received messages i.e. when the server receives a message, 
it gets a set of sequence numbers and it recognizes the 
sequence numbers missed then it calculates a packet loss 
percentage according to packets sent. In our conception, 
two scenarios are proposed; (i) if the packet loss ratio is 
lower than 50%, the RTO value will be updated according 
to formula (7) in order to prevent unnecessarily long idle 
time, otherwise, (ii) if the packet loss ratio exceeds 50%, 
the RTO will be updated in order to correct the loss 
according to formula (8). In other words, when the packet 
loss has a low value (pl < 0.5), we conserve nearly the 
same RTO value as the previous value (RTOtecent ~ 
RTOprevious ), this is in order to reduce idle time (waiting 
time). On the other hand, when the pl increases (pl > 0.5) 
the RTO conserve as well nearly the same value as the 
previous value, this is in order to correct the loss of 
packets. These formulas aim to adapt the RTO calculation 
to network conditions (RTT and packet loss) by 
conserving nearly the same value of the retransmission 
timeout. 


Initially, like the basic CoAP specification [15], we 
initiate the RTO to a random value between Ack_TimeOut 
and Ack_TimeOut*Ack_Random_Factor. Once the RTO 
is initiated, a message is sent to the corresponding client. 
Then after the reception of the message, the receiver 
calculates the RTT and the packet loss values based on the 
received packets and the sequence numbers. Afterward, 
the formulas (8) and (8) are used in order to calculate the 
following RTO to use in the next retransmission. 


RTOrecenn = RIT * packet_loss_ratio + (l- 
packet_loss_ratio) = RTOprevious (8) 
RTObecen = RTOprevious packet_loss_ratio + (1- 
packet_loss_ratio) * RTT (9) 


The detailed algorithm of our proposition is drawn in 
Figure 1. 
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RTO _imit-random(ACK TIMEOUT.ACK TIMEOUT*ACK RANDOM FACTOR) 
RTO = RTO_int 


For (i=1: i<packet.packet_nbr : i++) 
send_coap_packet ( ) 
packet pl=calculate_packet_loss ( ) 
packet.tt=caleulate_rtt ( ) 
receive coap ack () 


if (pl<0.5) 
then 
RTO=RTO*(l-packet.pl) + packet.rtt* packet.pl 
else 


RTO-RTO*packet.pl + (1-packet.pl)*packet.rtt 


endfor 





Fig. 1: Pseudo code of the proposed algorithm 


This proposition presents a dynamic and controlled 
retransmission timeout adapted to be appropriate and 
suitable for the IoT communications particularities. The 
two mechanisms presented by our proposition effectively 
limit the growth of RTO values since it is the previous 
RTO that makes the higher weight in each of formula (8) 
and (9). 


4.2. Adaptive multicast congestion control algorithm 


Experiences show that communications via unicasts 
between a single client and multiple servers automatically 
engender a congestion of the network. In order to reduce 
the problem of congestion, we proposed in [21] a simple 
adaptive solution based on the leisure defined in the RFC 
7390 [3]. 


Indeed, the fact that the CoAP congestion control, 
designed for group communication between a single client 
and multiple servers, doesn’t take into consideration the 
link delay to calculate the delay to insert between 
consecutive multicast requests, this leads to a congestion 
control mechanism insensitive to network conditions. 


Therefore, in order to improve the delay and to adapt 
the behavior of our solution to network conditions, we 
propose a delay between unicast requests depending on the 
link delay and the estimated group size as shown in 
formula (10). 


D= average link delay * G /G-1 (10) 


Furthermore, the link delay represents the behavior of 
the network; if it increases, it means that congestion is 
more likely to happen, so in order to manage this problem, 
the estimated delay between unicast requests has to 
increase. On the other hand, if the link delay decreases, it 
means that the network is more available and the delays 
between requests have to be short adapting its behavior to 
the condition of the network. 


To conclude, thanks to its flexibility and its ability to 
adapt its behavior to different network conditions, this 
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proposition consistently presents high performances and 
short response times; it has the ability to increase the 
number of successful transactions and to decrease the 
packet loss ratio. 


V. CONCLUSION 


IoT has offered the ability to transfer data between 
objects over a network using sensors without any human 
intervention. In this paper, two important research areas in 
CoAP based communications were highlighted. 


In the two cases of unicast and multicast CoAP-based 
communication, the number of transactions is very high 
due to the use of lightweight devices and constrained 
resources. Thus, in such a network, the problem of 
congestion is very frequent. Nevertheless, authors propose 
solutions for congestion control insensitive to network 
conditions, the thing that lowers its performances. 


In this paper, we seek to contribute to the current 
debate in the literature about congestion issue in CoAP- 
based communications. 


The scientific contribution consists of a conducted 
large-scale study describing some algorithms used to 
control congestion in CoAP based communications. 


Two suitable solutions to ensure safe network 
operation, while using network resources efficiently, were 
presented; unicast CoAP-based communication adaptive to 
network condition (an estimation of RTO value to use for 
the next transaction based on the packet loss ratio and the 
RTT of the previous transmission). Moreover, in multicast 
group CoAP-based communication an adaptive formula 
for the calculation of the delay to introduce between 
consecutive multiple requests was discussed. 
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